2016-10-05 - 28166 - BreakFix - Retail pro logic update for customer 0 #BWProductionIssues
Service Request
28164 - Retail Pro logic update for Customer 0
Problem Summary
Retail pro data load is failing due to the store '0', that is being sent with the data. There is no logic to handle it in BW as of now. This needs to be investigated and fixed.
Admin Info
Purpose
|
Need to fix Retail pro data load failures, caused due to store '0'.
|
Issue Date
|
09-10-2016
|
Resolved by
|
Naveen G
|
Resolved Date
|
10-05-2016
|
Document Status
|
Completed
|
Detailed Problem Description
Data load Issue on 09/20/2016 - For Master Data sources:
One of the BW extractors(based on view RP_PRD_MAT_RECEIVED_DATES) that fetch material dates information into ZMAT_DATE master data from Retail Pro source got failed today, as the materials got assigned to the new Store ‘0’. The logic is maintained in BW to handle for Stores ‘1’, ‘2 ‘, ‘3’ , but there isn’t any logic to handle the data for Store ‘0’. The data loads may fail in future, if the data gets extracted for store ‘0’ into BW.
Email from Pierre on 10/03/2016:
In a nutshell, it has been set up in Retail Pro since the deployment of the project. This store is used by the business to track products given to marketing or aimed to be discarded due to quality issues. Transfers will occur between real physical stores to this logical 'quality' store. I don't know how the other stores are technically managed in the interface / BW. What I know is that the business would like to track this store activities, transfers, products and value amounts on it so I would assume this store would be handled the same way as the others?
Solution Analysis and Recommendations
1. Retail Pro PC transaction data loads are failing daily as Store ‘0’ got extracted into BW. The ABAP logic in BW is set to handle Stores ‘1’, ‘2 ‘ and ‘3’ to assign a customer but for any stores, ‘#’ is being assigned in the logic and '#' value is treated as invalid character in BW.
2. The data loads for Retail Pro source will fail daily if this issue is not fixed & the delta records will not be available for reporting purpose.
3. These are the possible ways to handle the data load issue:
i. Assign a customer for store ‘0’ in all master data & transnational data loads.
ii. Assign a customer '9999999999' if any new stores get extracted in future.
iii. Write a ABAP routine to delete the records if the store is ‘0’.
iv. Exclude records with store '0' in DTP selection.
4. Retail Pro sources that are in BPD are not in sync with BPP, there are changes made to structures, ABAP logic & new mappings defined for DSO's & Infocube's collected in a transport request in BPD. If we start adding the logic for handling Store '0' in BPD and move them, the previous changes that are in BPD will also be carried out to BPQ & BPP. As we are not sure what the changes are made for, this may create multiple issues if changes get moved to BPP.
5. If a customer '0000000000' is assigned to store '0', then it will not show the transactions with store '0' under valid customer. Reports need to be carefully executed to avoid the exclusion of store '0' data.
Recommendations
1. As Retail Pro sources are not in sync across BPD, BPQ and BPP, it is not advisable to make the changes in BPD & transport to BPQ & BPP.
2. If customer '0000000000' is assigned to store '0' and '9999999999' for other stores, then it also need to have appropriate descriptions for identification in future.
3. Since the changes to the Retail Pro sources are pending in BPD for long time and there is also no request from Business past two quarters, it is suggested to sync BPD with BPP and delete the related transports.
Resolution
1. NEC advised to assign customer '0000000000' to store '0' and customer '9999999999' for all other stores, if any in future.
2. ABAP logic changes were directly coded in BPQ and validated with test data.
3. The same changes were then replicated manually in BPP and validated in detail.
4. Data loads of the delta request got completed successfully and the issue got fixed.
5. ABAP logic changes were made in the transformations updated to the following data targets:
Release Information
Logic changes are captured in a dummy transport request & deleted